Subject: Getting EBN XID parms from temporary link station control block

From: "Marcia Peters (8-444-4380)" <[email-masked]>
Date: Thu, 8 Aug 96 15:02:09 EDT

An issue exists when a node supporting HPR/ATM is also an EBN.  This note
describes the problem and a proposed fix.  (Printing is recommended!)

BACKGROUND
__________

The ATM architecture suggests that when a node receives a call, it use
assumed XID and link station parameters, until XID(np) when it learns the
TG number.  An implementation might well create a "temporary" LSCB
containing these assumed values, until it knows enough to reference the
real LSCB, containing defined values specific to that TG number, ATM
address, or partner CP.  (A node placing a call knows what parameters to
use because it can look in the control block for the ATM address it is
calling.)

EBN architecture has assumed that a node always knows how to set the ISTG
indicator on XID, based on its local definition for partner's subnetwork
affiliation (native/nonnative/negotiable).  Subnet affiliation is
currently defined on a port or link station basis, although it is
actually enforced on an adjacent-CPnane basis.

I can cite at least one case where wrong assumed initial values can cause
a subnet boundary to be created when it shouldn't be.

I don't know yet if worse cases exist.  If the temporary LSCB had wrong
assumed values for the partner's node type (EN/NN), its NETID, or its
EBN/PBN support, other things could potentially go wrong:

 - Create a peripheral ISTG when it should be an extended ISTG
 - Create extended ISTG when it should be peripheral
 - Link should not come up but it does
 - Link should come up but it doesn't
 - Link doesn't come up, and the wrong sense data is given.

PROBLEM CASE
____________

Assume that an EBN has an ATM port over which many SVCs can be activated.
These SVCs may include TGs to native and non-native nodes.  Assume also
that two EBNs have the same NETID.  One EBN defines the link as native
and the other calls it negotiable.

A call comes in and the first flow the EBN receives is an XID(null).  No
CP name is present, and, in the worst case, the caller's ATM address is
absent.  The EBN must decide what value to put in the ISTG indicator on
XID(pn).

Let's say the temporary LSCB's defaults are:  NN, EBN, non-native.  The
EBN sends XID(pn) indicating I am a NN, I am an EBN, here's my CP name,
this is an ISTG.

The EBN receives XID(pn).  The partner is an EBN and sets ISTG = 0 (it
thinks the subnet affiliation is either native or negotiable).

When the EBN finds the defined LSCB and learns that the TG should have
been native, it is not allowed to change the ISTG indicator to 0.  A
cluster boundary has been created inadvertently.

 +---+                                      +---+
 | E1|--------------------------------------| E2|
 +---+                                      +---+

             ATM call setup
   o----------------------------------------->o

             null XID
   o----------------------------------------->o
                                              |
                  XID (pn, NN, EBN, ISTG)     |      Using defaults from
   o-----------+        +---------------------+      ATM temporary LSCB
               |        |
   o<-------------------+
   |           |
   |           |  XID (pn, NN, EBN, ^ISTG, CPname)
   |           +----------------------------->o
   |                                          |
   |              XID (np, NN, EBN, ISTG, CPname)
   +-----------+        +---------------------+
               |        |
   o<-------------------+
               |
               |  XID (np, NN, EBN, ISTG, CPname)    Oops, it should have
               +----------------------------->o      been a native TG!

PROPOSED FIX
____________

EBN actually enforces subnet affiliation on a partner-CPname basis.  This
is because all parallel TGs to a given partner are checked for being the
same type (both ISTG, both non-ISTG).

EBN architecture already lets the EBN change its node type (EN/NN) and
flip the ISTG indicator from 0 to 1 between XID(pn) and (np) -- but not
from 1 to 0.  The EBN treats both these indicators as valid during
XID(pn).

This problem can be solved by having the right defaults in the temporary
link station control block.

This design is similar in concept to how EBN decides what node type
appearance to present.  The EBN and PBN indicators are valid during
XID(pn).  An EBN decides what node type to present in XID(np) based on
its partner's node type in XID(pn).  An EBN may change its node type
between XID(pn) and (np).

PROPOSED DOCUMENTATION OF FIX
______________________________

1.  HPR-06:
    Add defaults for temporary LSCB.  ISTG default = native.
    Other defaults - to be specified.

2.  EBN-03:

    a.  Define adjacent subnet affiliation on Define_Adjacent_CP instead
        of Define_Port or Define_LS.

    b.  If the adjacent CP's subnet affiliation is defined as negotiable,
        then once the EBN determines the adjacent CP's subnet affiliation
        (after first link activation and negotiation), all subsequent
        parallel TGs to the same CP, active at the same time, must have
        matching subnet affiliation value.  In other words subnet
        affiliation is enforced on a CP name basis, whether it is defined
        or negotiated.

    c.  Add FSM or XID flows showing XID(pn) and (np) processing when
        using a temporary LSCB.

    d.  Enumerate all the parameters affected by the use of a temporary
        LSCB.

Thanks to Gary Dudley and Ray Bird for helping find a solution.  I'd like
feedback on this proposal, please.

     Marcia

_________________________________________________________________________
 Marcia L. Peters, Senior Architect         Marcia_Peters @ vnet.ibm.com
 Advanced Peer-to-Peer Networking
 IBM Corp., Dept. BUFA, Bldg. 664
 P.O. Box 12195                             Phone:         (919) 254-4380